Color correction Albert, V453000 Factorio is in a state that even though is not yet finished, it is very close to its 1.0 version. That means that most of the work is done and we are polishing the game in order to make it bright. That's what we've been doing for the past 2 weeks. Literally making it bright. Since years I wanted to do this post-production work. But I didn't dare to do it until most of the graphics were finished. I was afraid of breaking the consistency of the look and our production pipeline. Now it's different. There's only a couple of entities to re-design and some other stuff to do, but in general this missing details are not affecting the possibility of working in the post-production. Factorio is a dark game. I mean conceptually. All these things about industrializing a planet, polluting an entire world just for the sake of the factory, and killing all its inhabitants are not precisely happy concepts full of light. This old article could explain better my thoughts regarding this concept. But the look of the game was dark, too dark. So we cleaned it up without betraying its spirit. Like restoring an old painting. The difference can be subtle, but very effective. We added more light, and a little bit of color saturation. Adding these general changes to the entire sprites collection is not an easy task. Many sprites were badly affected by this general correction. V453000 was fixing individually the broken sprites and icons in order to keep the consistency with the new context. We took the chance to work on the terrain a bit further. Not only this color correction was applied, but the contrast and integration with other terrains was also improved. Also experimenting with the color of the trees, trying to achieve a more colorful feeling with the excuse of an alien planet. I have to say the Alien Biomes mod was opening my mind - a little - to experiment with the color a bit further. In order to break this general brown feeling, we added a more orange tonality to the sand biome. Here is where you can see the difference more. Going further to too saturated colors is dangerous, after all, the terrain is a background that should provide a good and comfortable contrast with the entities and the icons. Touching terrain colours means touching map colors also. We were very keen to keep the visibility of the map information and the similarity with the terrain. The result is a more vibrant look in the entire game. We tweaked the night also. Thanks to posila and Wheybags, we can use LUTs (Look up tables) to dynamically modify the colors. Instead of playing with the alpha channel of a solid black layer on top of the game. Now we can gradually move to a different color palette for night with more control. So the colors are losing their saturation and becoming more blue and cold. This is important, because part of the annoying darkness of the game comes from this black layer. We are still experimenting with this LUT, and the transitions of day/night cycles. I'm pretty sure also that I will have to touch the map colors for some missing details and fine tuning. Possibly there is some entity that is not in its best shape with these new color palettes, and maybe we keep tweaking the terrain. But I feel very confident with these additions and I'm very sure that these changes will improve the experience of playing Factorio. After playing with these colors, the feeling is good. I hope you see it the same way.
Hello, We have had quite a peaceful week here in the office. Last night we went out for a burger and a beer as a last meal with Ernestas before he flies back home for another few months. It was also quite nostalgic, as we went to a place that we used to go to frequently near our old office, and the staff still remembered us.
Fluid mixing saga Dominik Hello Factorians, Today I would like to talk to you about my favourite subject - fluid mixing and its prevention. It is a new mechanic introduced in 0.17 that seemed quite simple at first, but has been giving me nightmares ever since. A while ago I took on the task of updating the fluid system (FFF-260). The way it works in 0.16 is that the fluid boxes (the thing that holds the fluid and is contained in entities like pipes or refineries) had no organisation whatsoever except their connections. They would sit there and do nothing and then once per update send fluid somewhere. It had it's issues especially with symmetry, and when you happened to put some fluid where it did not belong, you could end up requiring major demolition works. My task was to develop a better algorithm to move the fluids, and a very very optional side task I had in mind was to do something about the fluids getting to wrong places and mixing. We started by organizing the fluid boxes into systems (connected FBs make a system) managed by a special fluid manager, and optimizing the heck out of it (FFF-271). Soon after, I started working on the new algorithm and anti fluid-mixing. Until then nobody really considered preventing the fluid mixing seriously as it did not seem possible. But when I thought about it, it did not seem that hard. The idea is to simply not allow any action that would lead to fluids getting where they are not supposed to go. When you build a steam pipeline, you should not need nor want it to touch another fluid. In principle, it would only require a few quite realistic mechanisms: A connected block of fluid boxes would either be fluid-free, or it would be locked to one fluid. Two such blocks can connect only if they are compatible - either one has no fluid lock, or they have the same fluid. An assembler can only set a recipe if it is compatible with the fluid locks on its fluid boxes. Have a migration from old saves that can contain mixing. By creating the fluid systems right before, number 1 was almost finished and we only needed to assign the lock. It would be set either by a fluid, or by a 'filter', which is a fluidbox that is set to use a fluid - such as a water pump using water, or assembler having some inputs/outputs given by a recipe. After a while I had both the fluid algorithm and the mixing done (FFF-274). The mixing was not that easy (like 5x more complicated) but it worked pretty well. As for the fluid algorithm, V453000 and Twinsen found some issues with waves on a macro scale, and because it was right before releasing the 0.17 experimental, we decided to hold it off on it for the time being (we have a new version now that seems okay, but has to wait for 0.17 becoming stable first). The mixing made it through though and seemed quite finished. It turned out that the work on it was at most one tenth complete. Some difficulties appeared already before the initial release, but that was only a hint of what would come later. One by one, then ten by ten, bugs started coming. The problem is that as often as not, they were not just little issues with simple fixes. Instead, over and over, they turned the current solution on its head and the code had to be completely rewritten in order to account for the new case. As of now, almost exactly half a year and many rewrites later, it is still not fully bug free. The number one issue was with Assembling machines. It turned out that their code was pretty messy and does not simply allow the checks I needed, so it had to be refactored. The next problem was that the check was not only required when setting a recipe on an existing assembler - as I naively thought - but in about one million different situations I would not dream existed. Building a fixed recipe assembler. Reviving an assembler. Rotating. Blueprint of an assembler. Blueprint with a recipe and a rotation placed over a ghost with a non-default rotation during a full moon. Teleport. Script building. Copy-paste settings. Any combination of these. Pretty much every case would go through different paths in the code and behave entirely differently. Fixing one would break another and so tons of tests had to be written. When these cases finally worked, it turned out that doing these operations when they fail (e.g. can’t rotate because it would cause mixing) brings another wave of issues. And then mods come and the complexity multiplies. All this, although in a more simple form, had to be done for all other entities that can use fluid too, such as inserters (mods...). Another number one issue are underground connections. When playing, you would not think twice about them but on a closer look they are all but simple. They have this (cough) uncomfortable feature (want to shoot myself) that you can build another underground pipe between them (or take it out) and a complex reconnection logic jumps in. It means that based on building order, connections are established and reestablished differently. This is a big thing when building a blueprint with many pipes, or loading a save game. But the largest issue is one tiny corner case with huge implications. Have two underground pipes that have different fluids, but are split by a third, and it gets removed. Until now mixing was theoretically completely avoidable, but here it was and there was nothing to stop it. As a result, a new concept is introduced - a blocked connection. An underground connection that would normally connect but can’t. Establishing it is the easier part. But when does it get fixed? An entity miles away gets rotated, that splits a fluid system, disconnecting the blocked connection from a fluid filter on the other side, and the connection should unblock. But even something as simple as a rotation contains fluid fixes and re-establishing of fluid boxes and if it fails, it still fixes the blocked connection in the process and it can’t be undone... You get the picture. And we are still talking about underground pipes, while anything can have underground connections, including said assemblers, which the previous code did not consider at all. The complexity just goes deeper and deeper, and Rseding is probably right that we should have never gone this way at all. So the bug fixing has been basically running in circles - clearing one batch of bugs, thinking that those were the last ones and the ordeal is finally over, only to find another batch (ideally from some bizzare modder idea) a few days later. Many times I wished that mods never existed. Nor multiplayer, or any players at all for that matter. About two months ago all seemed really fine, with basically no reports and just a few crashes in the automated crash reports. At that moment another nightmare materialized in the form of a talented volunteer bug tester named boskid, who took on a personal crusade to break the fluids to dust (I actually imagine him sitting in his dark room with evil laughter, dreaming about making my next day worse than the previous). In all seriousness, he has done a great deal of work with his bug testing, creating bizzare modded cases and testing scripts, and deserves a big thanks. He is actually coming to our offices next week, so follow the news for reports of developers falling out of windows. An example of a nice configuration he found (and I can’t fix). The whole time we were taking the offensive approach to mixing - crash the game when it happens - so that we know about bugs to fix them. Recently we have decided to put a stop to it and have the mixing automatically fix itself once it is detected, eyeing the end of this episode. Right now I have 3 mixing bugs on the list and I am sure those are the last, and mixing will be done (lying to myself is a way to cope with it) and the new fluid algorithm can come soon after :).
Hello, Another week has elapsed, which brings us another week deeper into the declining weather of autumn.
A few bugs left... WoW classic has been released, which means several of our top men have taken time off to spend hours raiding and having fun in Azeroth. This isn't great timing, as a few new bugs related to train signals appeared. We want to get these bugs solved before we do another release (another stable candidate). As it turns out, the only person with the skillset to fix these specific train signal bugs is also deep into levelling his Priest... (Kov on Pyrewood Village) We are still making the rest of the preparations for the stable release. We have started writing up the stable annoucement blog post, and have produced a 0.17 postcard image. Other than the few more critical rail bugs, there doesn't look like there is much else to block the stable release, on the forum we are down to 27 bugs. Since there are so few bugs left to deal with, some of the team has starting working on 'post-stable' features. Wheybags is working on the new campaign, Oxyd is diving into some detailed pathfinder improvements, and Rseding has started work on some particle optimizations. We will delve deeper into these topics and more in future FFFs, as we always love to do.
Crash site: First state Ernestas, V453000, Albert For many weeks now the GFX department has been focused on preparing replacements for the placeholder graphics of the campaign crash site. The subject as usual is not that easy because we had to first solve the main concept of the crash site. It happens that those new entities belong to the Factorio universe, but they come from a different reality than the usual DIY/diesel punk of the game. So we had to invent a new way to design machines that look like Factorio but that are not too familiar. Here a proof of concept of the look: The concept is that the big (medium) spaceship broke into pieces as it crash landed, and lost many components that the player, during the introduction, will repair and use for his own profit. The look of the spaceship remnants are a little bit based on the designs of the 60’s/70’s pulp Sci-Fi. Fortunately we can keep the look of Factorio due the accident, which allows us to destroy and dirty up the machines show many inner mechanical details. It is also part of the concept that all the machines that the player builds, are based on an existing technology from his home planet. So the machines that we see in the regular game are like 'cheap' versions of the original ones. For the lab, we keep the dome shape and the beams inside in order to keep consistency with the regular laboratory. So slowly the player gets used to the meaning of the shapes. The generator is similar to a substation -more or less-, connectable like a pole but it also produces electricity. Sometimes we really have to invent. This works like an assembling machine. The design is more based in the (yet unshown) redesign of the assembling machines, rather than on the actual 'classic' ones. These cylinders are like chests. We decided to make them cylindrical instead of a box for this difference in technology level that we are speaking about. The player will recognize them for the shape, color, and they also always have a number printed. You don’t really want to know the meaning of the numbers. All this new content is a work in progress, and we made these new entities first for the testing of the campaign. Based on feedback with testers we will have the chance to tweak and adapt whatever is necessary. In the case of the introduction, the positioning of the entities can have a large impact on the flow of the gameplay. Once we are more sure of the final placement, we can see how all the pieces will fit together. The next round for the crash site is the main crashed spaceship, and some other assets that converts the scene into a full composition, more proper for the introduction of the game.
Hello, the bugfixing period boringly continues, we got down to 159 active bug reports, so in few weeks we should be finally down with this burden. But at least the graphics department has something new to show:
More remnants Dom, albert As for the conclusion of the topic opened in the FFF-288 we finally decided to go for a balanced solution in which the player can recognize what entity was destroyed and also walk through them. The solution of going up in the Z-axis is really attractive for designing the destroyed models, but it gives a lot of headaches to the game designers due its need of a bounding box. We are planning also a generic set of remnants for the modders who don’t feel like making the destroyed version of their own machines. Here an example of how a factory can look after a biter attack: These remnants are still a work in progress, many of them are not yet finished and we are planning more iterations with this subject. By now you'll find a sneak peek in today's release (0.17.36).
New Campaign Abregado Have you ever been playing a Freeplay game and realised you don't know what your next big goal is? And then, once you decide to pick a new goal, you realise while you worked on automating the last goal, there were 10 new technologies unlocked and now you don't know which to pick next. These are the situations we hope to address with the new full Campaign. A guided Freeplay, in which the player plays through the whole tech tree, without being overloaded with choice, while still having the permanence and unidirectional progression of Factorio. The permanence problem has already been solved using the new map expansion technique which is playable in the Introduction scenario. Over the last year we have been working on the bigger design task of unravelling the tech tree and breaking it into a set of choices for the player. This task has been made all the more Interesting as the tech tree is also constantly getting tweaks and revisions over that time as well. I look forward to providing more insights but for now I will leave you with one example (read: spoiler): Just to note, we won't be changing the freeplay tech tree, which will still have all the choice and diverging paths as it does now.
